|
Post the code using code blocks.
You can debug by removing the dynamic blocks until only the first one is left.
If that works then add one dynamic block at a time.
Also rather than trying to remove the last term add a first fixed term. Thus your constructed where would look something like...
where 1=1 and p_Niin like '%x%' ...
|
|
|
|
|
Thanks... I didn't even think about fixing the first base where clause string like that. Much easier. and yeah, I've just been moving through the if statements. I'm sure there's just a quote or something missing.
|
|
|
|
|
Hi there! is there a way to disallow multiple connections for a login? During login, I would like the server to check whether the login is already connected or not. If it is, I would also want to send a message to the user's client that the login used is already connected. I just want to avoid the case where a user may run a client more than once with each instance connected to the server. Thanks in advance.
|
|
|
|
|
Assuming you are using SQL SErver (we need to know this as servers are different).
I would expect this to be a client requirement, most apps use a SQL Server set of credentials to connect. However sql server can identify the workstation connection if it is in the connection string and if you are using Windows authentication yeck the database knows who you are.
You can always rat through the sysobjects and find this information, it will be a challenge getting the connection event and informing the client. As said this should be done at the client.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks Holmes. I was wondering whether there is a command to set this check on the server. With the presence of the 'InfoMessage' event in the 'ADO.Net' provider, I thought of sending the message from the server so that it will be trapped in the 'InfoMessage' event for the client.
My first try was checking the connection and login from 'master..sysprocesses' using the client. I think I will have to stick to that if it will be difficult doing it on the server and also send the message.
|
|
|
|
|
I don't think what you describe would work very well -- what if the client crashes and tries to get reconnected?
What I do is have the login process assign a GUID to the "session" and the client must provide that GUID with each following access. But I have a second login effectively log the other session out.
|
|
|
|
|
Dan_K wrote: I just want to avoid the case where a user may run a client more than once with
each instance connected to the server.
Why? That is really a problem for the client app, not the database.
|
|
|
|
|
I do understand your point jschell. But I want to know how the database server can provide support. In Win32 API programming, FindWindow() can be used to detect whether the client application is already running on the computer so that I disallow multiple instances. I wrote the client application in .Net but I do not know the way around it in this Framework.
But even if that is solved, a user can run the client application from different computers using the same login name. That's what I want to avoid and the reason why I am thinking of a support from the database server.
|
|
|
|
|
Dan_K wrote: a user can run the client application from different computers using the same login name
That is a different issue to the multiple logons. PieBalds response addresses this, if you don't kill the initial session you are going to run into timeout issues. How does the server know if the initial client logon has not in fact logged off the client - you don't.
There is not built in server functionality for this as it is not a server function. There have been many kludges to address the issue, keeping track of connections/logons etc. All have their shortcomings.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Dan_K wrote: That's what I want to avoid...
Still back to my point - why is that a problem?
What business requirement is going to fail if it does happen?
|
|
|
|
|
Well, users will be working on confidential data. I have been thinking of more possible threats and thought that a user may give his/her login details to someone not supposed to be part of the work who may connect from another system just to influence the results in their favour. jschell, do you think it cannot happen?
|
|
|
|
|
Dan_K wrote: Well, users will be working on confidential data.
Define what type of "users". A help desk person? Operations? A consumer?
Dan_K wrote: I have been thinking of more possible threats and thought that a user may give
his/her login details to someone not supposed to be part of the work who may
connect from another system just to influence the results in their favour.
I don't know what the last part of that means but as for the first exactly what are you doing to protect from the following scenario?
User A gives their credentials to X.
User A works on something then logs off.
User X logs on then does something 'wrong' then logs off.
|
|
|
|
|
Your client can place locking records in your database to point out that a user has loged in (like semaphore locks). At closure of the client the record must be removed.
In our system we have a special server application that checks every minute whether a lock is still valid, and otherwise removes it. Upon a crash of a client you wont have a lockout for long.
To be able to see who has accessed the data, you could make an audit system:
Log which user signed in from which computer, what he has done etc.
This can be done by various methods:
- the client app writing extra records
- triggers in the database
- the higher versions of SQLServer have tables that store information about performance of performed queries etc. Maybe those are helpfull also.
- ...
Regards ... OttO
|
|
|
|
|
Hi Dan, I don't know what programming language you are using, but here is the logic. I'm sure you can apply it on any language;
1. Create a shared folder with read/write authorization for Everyone on the server.
2. In my apps, every user has their own GUID primary key on the database.
3. Suppose one user has a primary key 0D5FF2C1-9710-47EF-86FE-164E6170EEFD . Each time this user log in to the system, check if there is a text file named 0D5FF2C1-9710-47EF-86FE-164E6170EEFD.TXT in the shared folder on the server. If it doesn't exist, go to step (4). If it exists, try to delete it. If the deletion success, then continue to step (4). If the deletion fail, then other workstation is using this login ID is being used. You might want to show some message and redirect the program flow to the exit routine.
4. Create a text file named 0D5FF2C1-9710-47EF-86FE-164E6170EEFD.TXT on the server and keep it open while the apps is open (don't close the file handle).
5. Upon exit, close the TXT file handle and delete the text file.
By locking the handle, as long as the user is login, other client could not delete the file. If the initial client crash somehow, then the lock to the text file would be released by the server OS, thus, other workstation would be able to delete the text file (and login with the user id).
Others might have better solution. Yes, this is not a SQL solution. And might not be elegant enough for most programmers/system developer. But it works 
hth,
foxyland
modified 8-Mar-12 4:13am.
|
|
|
|
|
Hello
I did a stock control app in vb.net that uses an Access 2007 db.
I connect using ACE.OLEDB.12.0
The Access db is located on the server, and the app is loaded on the workstations.
They make a backup of the Access file every night. (Simply copy and paste to another location)
There are about 10 users, reading and writing the same tables
They have been running for a week so far, and up to now have already had one error where when trying to access data I got an exception " Unable to access the database"
From comments on the net, Access is a really bad idea (Corruption, slow connections in multi user apps etc etc)
They are a small company, so a licensed SQL2008 server is not practical financially.
MySQL seems like a logical free option?
My Questions:
1) As a temporary fix while migrating to a 'proper' db, I have read about creating a second access db, and linking all the tables in the 'back-end' db, to the 'front-end' db, so that if the first db gets corrupted, the 'back-end' db will remain in tact. Does this seem like a good idea?
2) Is MySQL the best choice for a db in this situation?
3) How easy it it to install and configure a MySQL database
4) Are there connection objects in .Net for MySQL (I saw an ODBC connector on the MySQL download page - is this the best way to connect?)
5) How do you back up a MySQL Db - do you need special agents?
6) Are there any other problems/differences I should be aware of when going the MySQL route? (I have noticed some differences in SQL syntax, parametrized queries etc, and also I use AutoNumber fields in Access to get unique Sales/Purchase Order Numbers
I would be appreciative of any comments!
Thanks in advance
Richard
modified 26-Feb-12 1:20am.
|
|
|
|
|
Have you given any thoughts on using SQL Server Express?
It can do everything Access can do better, integrates very well with .net, gives you powerful upgrade options and is for free. (until you upgrade that is)
|
|
|
|
|
1) This is valid when you have both the UI and the data in Access, your UI is in VB.net so this scenario does not apply.
2) No - MySql has less support than SQL Server and Oracle (and there are other good options out there). I would recommend SQL Server Express (relevant limitation is 4gb database size) as there are a MUCH wider resource base for support and training. There is a valid upgrade path though you then need to pay. And there are many more human resources (potential employees) with SQL Server skills.
3) Very easy, the gotchas are minimal, case sensitivity (none) and collation are the one I hate, just accept the default.
4) Connection strings
5) No idea but there will be a MySQL support site dedicated to this type of question (I just don't know it)
6) SQL server used to provide an upgrade wizard for Access to SQL Server, not sure it MySQL does the same.
As you may infer I am not a fan of MySQL (also no experience) and would urge you to use SQL Server.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
2) No. I use MySQL only when I have to. For small configurations like yours I recommend SQL Server Express 2008R2; it works very well, much better than Access, and has excellent support in .NET
|
|
|
|
|
2) No. SQL Server Express.
4) An ADO.net connector (not ODBC) for MySQL is downloadable; I use it to read MySQL databases created by others when I really need to.
|
|
|
|
|
Just like the rest, Use SQL Server Express 2008 R2 with management tools.
It has a 10GB limit per database. Other then taht it sure beats the hell out of Access.
If you really wanna go for open source then I reccomend PostGreSql over MySQL.
Still, I highly recommend SQL Server Express 2008R2 for the simple fact that your app is in .net.
All the best,
Dan
|
|
|
|
|
Long time since I used Access so this may not apply. When backups were done we always did a compact of the database (it's a menu choice IIRC). In a similar situation to what you describe never had any real problems with Access in 5 years or so. The front end was VB6 and the back end was just tables and queries on the server. So may be something in your set up you can tweak.
However, I'd support the suggestion of looking at SQL Server Express. I've had a little experience with MySQL (on Linux) and found no problems with it. So I would not rule it out completely. I think however that SSE is probably a better bet. There are others like SQLite around(though I don't think that's appropriate for what you describe) so may be worth investigating.
Regards
David R
---------------------------------------------------------------
"Every program eventually becomes rococo, and then rubble." - Alan Perlis
The only valid measurement of code quality: WTFs/minute.
|
|
|
|
|
|
craig trombly @ infobright wrote: How do you keep the database tuned for queries when you do not know what the query will be?
You don't tune for a query; indexes aren't linked to queries, but to fields in a table (or a view). Put indexes on the fields that are used for searching and filtering. You can even ask Sql Server which indexes are used most frequently and which aren't, so it could automagically fine-tune itself based on recent usage (the server keeps statistics, so it "knows").
craig trombly @ infobright wrote: but when the CFO wants to look at common trends against the corporate database for spending with daily, weekly and monthly increments for sales engineers in the northeast regions......
I don't see a problem there.
craig trombly @ infobright wrote: Take a look into why an analytic database is becoming a vital concept into the business intelligence communities at http://www.infobright.org
Ah, so this is an ad? 
If you want to introduce something new to the community, then please submit an article; the forum is more fore live discussions, and lots of new posts will move this one to the back, and people will forget about it.
Bastard Programmer from Hell 
|
|
|
|
|
Eddy, Thank you for letting me know. This is not an ad though. What I am trying to do is to get people talking about analytic databases and to encourage the use and understanding of them. I do appreciate the feedback from you.
|
|
|
|
|
craig trombly @ infobright wrote: What I am trying to do is to get people talking about analytic databases and to encourage the use and understanding of them
Then why did you post
craig trombly wrote: Take a look into why an analytic database is becoming a vital concept into the business intelligence communities at http://www.infobright.org
Not cool.
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
