I am trying to run my application in debugging mode. Logon screen appears and when I try to login "context::Context(void) - cs_ctx_alloc() failed" error is encountered.
On debugging using break point and selecting continue when the code crashes, following Database Access Error Message is displayed
Following are the environment setup in which I am finding error.
OS: Windows 10
IDE: Visual Studio 2013, VC++ Code
Database: Sybase OCS 15_0
The application is working well on following environment:-
OS: Windows 7
IDE: Visual Studio 2013, VC++ Code
Database: Sybase OCS 12_5
My task is: Our users get from their chemical suppliers some tables do determine the required quantity for chemical Y based on the given quantity of chemical X.
BTW: The task is_not_ to find a linear regression formula.
Easy example- 2 Dim: Depending on X the component Y has to be used with different quantities:
X Y= f(X)
In Praxis this will be not only y= f(x) it is more r=f(x,y,z, ...) and much more it is (r, s, t, ...)= f(x, y, z, ....) but the later is not the discussion here.
Now I'm asking me how one can design a General database layout with a constant number of tables/fields to save an N dimensional function.
With constant number of tables/fields I mean I don't like to solve this task by creating "dynamicly" columns according to the bigest dimension in use... or so
Note: I have also to say most probably I’m not going to save this kind of data in a set of related tables, but anywhere I’m interesting how one would do it theoretically, maybe this gives me some more ideas and last but not least to learn.
The dimensions are usually around 3 to 5, but I like to solve: How can one design a General Database Table Layout -for N dimensions - for this task?
Is started like this
// TBLS: The Main Table to define a specific N Dimensional User- Function)
// TBLS_BASES: In this table the bases of the User Function will be defined
TBLS_ID (P) FK: TBLS.ID
// TBLS_BASES_VALUES: In this table the bases values will be defined
TBLS_ID (P) FK: TBLS_BASES.TBLS_ID
TBLS_BASES_ID (P) FK: TBLS_BASES.BASE_ID
VALUE // The base value, basically the candidate for PrimKeySeg, but // replaced by POS for the sake of simplifying// TBL_VALUES: The table to finally save the function values. Here I have my big problem
TBLS_ID FK: TBLS_BASES_VALUES.TBLS_ID
TBLS_BASES_ID FK: TBLS_BASES_VALUES.TBLS_BASES_ID
POS FK: TBLS_BASES_VALUES.POS
VALUE // Finally the function value
Now an example for three dimension z= f(x, y)
First the three "base" tables for the function
I draw your attention to the statement at the end of the article
SQL Server does a pretty good job in deciding which join operator to use in each condition. Understanding these condition helps you to understand what can be done in performance tuning. It's not recommended to use join hints (using OPTION clause) to force SQL Server to use a specific join operator (unless you have no other way out), but rather you can use other means like updating statistics, creating indexes or re-writing your query.
Given the way you have worded your question I would just stick to using normal join syntax and allow SQL Server to do the decisions on how they are physically implemented.
I have an application which reads all the Jobs and its related packages which failed, but its reading only those Packages which are executed as part of the Jobs. Is there any way that I can check all the Packages that are failed like the ones that are executed externally like from an Application or Manually etc.
The code to get the failed packages that are part of the SQL Agent Jobs:
I am looking to create a tool for my office to simplify the storing of certain logs. Right now it is done via excel and during weekly calls the staff needs to organize this and distribute to recipients, update daily, etc.
I am thinking (thinking) if I went to a Database application I could write a better means to store the information and more importantly add some code to have a button (for example) to email all of the reports to anyone in the database flagged as a recipient.
This is just one small first step of functionality as I aim to overtime add more and more slightly to it.
I am thinking that I could put a template of the database in each project folder and have people just manage it that way so I dont have to worry about too many concurrent users. It also simplifies the location of the storage vs a central place everyone gets to it (which means they forget since they are in the project folders all the time).
Alternative, is I just start the endeavor of writing a true .net application on top of the database. Although I am thinking this is more future proof as I honestly dont know where this would feature wise I am thinking it would be way more complex and lengthy on development time.
So how do you weigh where to build the application? I can probably knock out basic functionality in access relatively quickly, but am I limiting myself?
If you NEVER expect to consolidate the data then Access on each client is a viable option.
However I would start with SQL Server express and a Winforms/WPF client application.
Access will give you a quick and dirty solution with a minimal learning curve. You will run into limitations fairly quickly, especially when you decide you need to consolidate the data for whole of company reporting.
SQL/Client will have quite a steep learning curve, however it is a professional environment and you can plug in a professional developer when you reach you limitations.
This is an ideal project for a junior developer just starting out, they get to learn the skills of analyst and application design and you get to manage and learn the development skills.
Never underestimate the power of human stupidity
Thanks for the response. The combination of data is not a big deal as I could always recreate a unified solution later. It never would really hurt me. I am just torn on how useful a standalone DB will be. If not useful, it won't get buy in.
I am sure this may not be well received in these forums but I have been researching Mendix a lot. Model based development takes the technicalities out of it. Any thoughts on that? Seems like it could be a good route to go.