hi -
can somebody tell me pls wtf is the benefit when using SQLExpress instead of 'normal' ODBCDBE?
SQLExpress also connects via ODBC - so:
is it faster? (how could it be...)
is it more stable?
what is the reason to use it?
Thks
Michael
SQL via SQLExpress or pure ODBC
Re: SQL via SQLExpress or pure ODBC
Michael -
I have never really compared performance of the ODBCDBE and SqlExpress, but I suspect that SqlExpress may be faster because it bypasses the Xbase++ DBE system.
Maybe somebody has some comparison statistics.
Roger
I have never really compared performance of the ODBCDBE and SqlExpress, but I suspect that SqlExpress may be faster because it bypasses the Xbase++ DBE system.
Maybe somebody has some comparison statistics.
Roger
The eXpress train is coming - and it has more cars.
Re: SQL via SQLExpress or pure ODBC
Hi Michael,
SQLExpress has more and expanded features and less limitations than the Alaska offering.
Additionally, I suspect that support from Boris will be faster than requests made of Alaska.
My 2 cents,
Rick
SQLExpress has more and expanded features and less limitations than the Alaska offering.
Additionally, I suspect that support from Boris will be faster than requests made of Alaska.
My 2 cents,
Rick
-
- Posts: 33
- Joined: Wed Jan 27, 2010 10:23 pm
Re: SQL via SQLExpress or pure ODBC
Thank you guys..
but Alaska's ODBCDBE gives me the opportunity to stay in the syntax I am used to..
it automatically loads all the indexes - and I can use DbSeek() - adress all fields
by their native name instead of calling oCursor:FieldGet('Customer') which could
result ina delay if you have 200 or more fields - and it gives me the opportunity
to keep all the code of the main program logics...
I really fever to hear some speed experiences..
Thks
Michal
but Alaska's ODBCDBE gives me the opportunity to stay in the syntax I am used to..
it automatically loads all the indexes - and I can use DbSeek() - adress all fields
by their native name instead of calling oCursor:FieldGet('Customer') which could
result ina delay if you have 200 or more fields - and it gives me the opportunity
to keep all the code of the main program logics...
I really fever to hear some speed experiences..
Thks
Michal
-
- Posts: 103
- Joined: Fri Sep 17, 2010 2:58 am
Re: SQL via SQLExpress or pure ODBC
Hi everyone,
I'm also very interested in this topic, as I am trying to re-code an existing xBase++ application using the MS SQL. Currently I'm trying to use SQLExpress.
The trouble that I have is that I need to maintain the same UI and user experience, which sometimes can be quite difficult to achieve without changing the logic flow.
So I also want to hear from the gurus out there, should I continue to pursue my goal using SQLExpress or ODBCDBE would make my life much easier??
Regards,
Andy
I'm also very interested in this topic, as I am trying to re-code an existing xBase++ application using the MS SQL. Currently I'm trying to use SQLExpress.
The trouble that I have is that I need to maintain the same UI and user experience, which sometimes can be quite difficult to achieve without changing the logic flow.
So I also want to hear from the gurus out there, should I continue to pursue my goal using SQLExpress or ODBCDBE would make my life much easier??
Regards,
Andy
Re: SQL via SQLExpress or pure ODBC
I am working with a customer who needs access to a Microsoft RMS (Retail Management System) SQL database.
He had a lot of problems when trying to use the ODBCDBE.
He says that everything is perfectly solid now that he is using SQLExpress.
He was not aware that the eXpress++ browse system automatically handles SQLexpress cursors and was delighted when I showed him how easy it was.
It is really not difficult at all to move away from the work area concept (DBE) and adopt the SQLexpress concept (OOP).
Look at the SQLexpress sample program in \exp19\samples\sql.
He had a lot of problems when trying to use the ODBCDBE.
He says that everything is perfectly solid now that he is using SQLExpress.
He was not aware that the eXpress++ browse system automatically handles SQLexpress cursors and was delighted when I showed him how easy it was.
It is really not difficult at all to move away from the work area concept (DBE) and adopt the SQLexpress concept (OOP).
Look at the SQLexpress sample program in \exp19\samples\sql.
The eXpress train is coming - and it has more cars.
Re: SQL via SQLExpress or pure ODBC
Hello,
I had also bad experiences with ODBCDBE and the Alaska support regarding the failures. After changing to SQLEXPRESS I had never problems again, and I use one of the first versions from Boris. The only problem I still have, is to browse large databases. The select statemant takes too long.
Regards
Rudolf
I had also bad experiences with ODBCDBE and the Alaska support regarding the failures. After changing to SQLEXPRESS I had never problems again, and I use one of the first versions from Boris. The only problem I still have, is to browse large databases. The select statemant takes too long.
Regards
Rudolf
Re: SQL via SQLExpress or pure ODBC
I am working on a "workarea" concept that will work with SQLexpress cursors.
It would only work without the alias operator, but otherwise I see some possibilities here.
It would only work without the alias operator, but otherwise I see some possibilities here.
The eXpress train is coming - and it has more cars.