Thanks in advance!

Mike

• SQL Server (no embedded editions)
• Oracle
• VFP
• Access

If you need to connection to a different type of OLE database, then that is fine and SF will work, but you will have to manually supply the connection string:

When you do this you will place this code in the Appmain.vb SetDataSourcesMethod and then remoce the SetConnections line (as this forces the Connection Manager to be used).  Also, there is a lot of information about connection strings and setting them up manually within the help docs as well.

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(New OleDbDataSourceItem("PREMFRAME", "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=C:\Users\michthom\Documents\Visual Studio 2008\Projects\premframev2\premframev2\premdatav2.sdf;"))

it tells me that OleDbDataSourceItem is not defined

i know i am missing something here.

Please point me in the right direction as I cannot find anything on this provider in SF help.

Mike Thomas (09/11/2008)

---

I hope someone can help soon

I'm sure someone will be along shortly with the magic answer. Hopefully like Greg said it is just an assembly we are missing (I hope). I am excited to get my new project working using compact databases, it will make deployment much easier for a relatively simple product.

The fact that Trent posted to use the OLE provider, with source code above, makes me feel good about a quick resolution.

Using SqlDataSourceItem on Embedded Editions
Now if I am not mistaken, if you are trying to use SQL Server Everywhere (or a compact edition of SQL Server) then you can use the SqlDataSourceItem and then specify the OLEDB provider or other supported SQL provider as part of your connection string and it will work just fine.  Ths SQLCommands should support the SQL Everywhere editions as I am pretty confident that this is the approach a number of our developers are using for this embedded data source.  But in the case that you are using something other than an SQL edition, then you will need to create the data source mentioned above.

This can also be impacted by the version of the Mobile SDK being used, etc.

Also, there is more than one way to connect to a Mobile version of SQL Server...you can use the SqlCeXXX commands and namespaces which would require you to create your own data source (mentioned above) or to use OLEDB or ODBC, which both of the latter mentioned should be able to use the standard SQLConnection and SQLCommand as well as the SqlDataSourceItem classes.

Finally, Keith, the DDT does not support a compact or embedded edition of SQL Server...this is a totally different platform and would require major changes to the DDT in order to work.

As far as the DDT goes thats fine, I'll do what I did for the MYSQL provider, create a SQL Server mirror of the database just for BO Mapper.

Is adding official support for SQL Compact on the radar?

Thank you for your answers.

Yes...but it is a very faint blimp   There are a number of other more highly demanded things ahead of this...so though this is something that will definitely be part of the framework, it may be a while.  Probably the next major release (SF 2.0).

PS - Cowboys 21 - Eagles 30 Monday night

tried to rebuild microfour.strataframe base and got the following error...

Error 1 The command ""C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Base\AfterBuild.bat" "C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Base\bin\MicroFour StrataFrame Base.dll" "C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Base\bin\microfour strataframe base.xml"" exited with code 9009. microfour strataframe base

was i doing the right thing?

Try the following:

1. Close down all Visual Studio Instances
2. Open two Explorer Windows.  Navigate one to the "C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Base\bin" folder and the other to the "C:\Windows\Assembly" folder.
3. select the "MicroFour StrataFrame Base.dll" from the bin folder
4. Drag the selected file into the "c:\windows\assembly" folder (GAC)
5. Also copy the "MicroFour StrataFrame Base.dll" and the "microfour strataframe base.xml" to the "c:\program files\common files\microfour\strataframe" folder
6. Your assemblies will now be on the latest build.
7. Go back into Visual Studio

Well...you know, the other day Charles Hankey sent me something prior to the Browns game...and well, we know how that turned out.  So I will wait until next Tuesday before I say too much...but when the Boys win ... then I will have more to say

Do you know if by getting that error that anything was rebuilt?  do i need to take out the post build event out to get it to rebuild successfully first?

Thanks again everyone!

Secondly, you should not be changing the SF source code, which it sounds like you are doing.  You should create your DbDataSourceItem in one of your assemblied, not the SF base assembly.  You NEVER want to change the SF source if you plan to ever receive another update.  This is why you want to create your own base assembly which references the SF Base and then either inherit and override logic or create your SF inherited classes there so that when you get a new version of SF it doesn't wipe out your code and require you to go back and keep putting things in.

The provided SQLDataSourceItem will not work due to differences in features support between SQL Serevr and SQL compact. Basic stuff like schema designation, use of IDENTITY_SCOPE are not supported and must be removed from the SQL commands. I went down the road of creating a SQLCEDataSourceIitem that uses the System.Data.SqlServerCE namespace and have had good results so far. I have basic databinding and UPDATES working using the following in appmain.

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(New SqlCEDataSourceItem("", "Data Source=C:\ioivb.sdf;"))

Again, if someone out there gets either the BOMapper or SF in general to work with less effort using OLEDB, I would appreciate a heads up. If anyone is interested in the SQLCEDataSourceItem, let me know. It will only have the "_NONSP" items done, but it will work.

Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=C:\Users\michthom\Documents\Visual Studio 2008\Projects\premframev2\premframev2\premdatav2.sdf

i think i don't understand the framework enough to do what trent is suggesting.  I would love if someone had a sql compact code example i could customize for my file.  I do really need to use the desktop edition so i am not sure what to do

Thank you for posting this. On a PC that has a good install ( ) I got OLEDB working.

1) Created OLEDBSOURCE class

2) use #1 in appmain:

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(New OLEDBSOURCE("", "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=C:\ioivb.sdf"))

3) Change my fills to use OLEDBCommand instead of SqlCommand

Just curious... what are your reasons for not using SQL Server Express?

do you have some experience with sqlexpress and distributing?

Even if you choose to do this yourself, you can download the SQL Server Express redistributable and via command lines install it very easily.  SQL Server is also easy to test for in regards to services if you take the manual approach.  We use SQL Server Express in a high percentage of our medical software user base and so we have to test for and install SQL Server Express if needed.  This is really one of the easier parts of the install.

If I had to choose between those two it would be Access.  FoxPro is nothing but a problem waiting for a place to happen...this comes from MANY years of experience. 

But in truth, I would not use either of these, but SQL Server Express.  I know that this post has been geared around embedded database conversation, but there is a reason that we have not yet created a data source item for this...there is generally a better solution.  I do see the benefits of a disconnected laptop for the day, etc.  But even then I would tend to lean towards SQL Server Express.  First of all, it is free.  Secondly, it is faster and a full version of SQL Server.  Additionally, you don't have to deal with data type issues.  For example, SQL Mobile doesn't have a VarChar data type but only a NVarChar (unless something has changed recently).  Not that using an NVarChar is bad, but it just might not line up exactly with the desktop structures (if you a.] have the need or b.] ever plan to have a larger version of an application).

In my opinion, and if I were hired in a capacity for consultation purposes in a situation like this, I would tell my client that they are better off developing on a full SQL Server version versus an embedded edition....I have a lot of embedded experience from years past and there are other issues that you will inevitabely run into (i.e. row locking, etc.).

That being said, my current project is VERY simple as far as data goes as it mostly does scanning and image manipulation, and will be single workstation only, so SQL Compact I think will be the right choice based on past experience with it.

The attachment is a very simple working sample that uses SF 1.6.6, the ADO .NET Provider for SQL Compact 3.5 (had issues with OLEDB updates I couldnt get past) included with VS2008, and the System.Data.SQLServerCE namespace used to create a SQLCEDataSourceItem. I tested with OptomisticRowVersion since that is what I use. Just slap the SDF file in the ZIP onto the root of your C drive and it should work. Good luck and I hope it helps someone.