Btw, is there a way for the generated enum.cs file to be added to the DatabaseGeneric project?

I don't understand? Do you want to append to an exsting file? That is not possible with this version.

wayne wrote:

Btw, is there a way for the generated enum.cs file to be added to the DatabaseGeneric project?

I don't understand? Do you want to append to an exsting file? That is not possible with this version.

He just wants the file to be placed in the same folder as DataBaseGeneric, instead of the project location. Drag and drop worked fine for me though.

Actually, at the bottom of the screen you can tell it where to generate the files.

Hi obzekt

Try to recompile the source. It is shipped with task performer. According to Otis none of the connection string things changed. He suggests that we try a recompile of the source. - The errors might be due to changed version numbers since the last recompile.

Skeeterbug, did you try the taskperformer with the new LLBLGen yet?

Yes I just tried it, works fine.

wayne wrote:

Try to recompile the source. It is shipped with task performer. According to Otis none of the connection string things changed. He suggests that we try a recompile of the source. - The errors might be due to changed version numbers since the last recompile.

I recompiled the source, copied Get_Enum.DLL in the TaskPerformers folder, restarted LLBLGen Pro (the latest designer assemblies from 7/12), refreshed the catalog providing the sa password, generated the adapter DAL fine, then tried to generate the enums and got the same "SQL Server does not exist or access denied" exception. Here's the stack trace:

-----[Core exception]-------------------- at System.Data.SqlClient.ConnectionPool.GetConnection(Boolean& isInTransaction) at System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnectionString options, Boolean& isInTransaction) at System.Data.SqlClient.SqlConnection.Open() at Gen_Enums.Performer.Get_Dataset(String SQL, String ConnectionString) at Gen_Enums.Performer.Perform(IGenerator executingGenerator, ITask taskDefinition, Hashtable parameters) at SD.LLBLGen.Pro.GeneratorCore.Task.Perform(IGenerator executingGenerator) at SD.LLBLGen.Pro.GeneratorCore.TaskGroup.Perform(IGenerator executingGenerator) at SD.LLBLGen.Pro.GeneratorCore.TaskGroup.Perform(IGenerator executingGenerator) at SD.LLBLGen.Pro.GeneratorCore.Generator.Start(ITaskGroup tasksToExecute, Project projectDefinition, TemplateSetDefinition templateSet, ApplicationConfiguration configurationSettings) at SD.LLBLGen.Pro.Gui.Forms.MainWindow.StartGeneratorProcess()

It doesn't seem that I am doing something wrong because the catalog is properly refreshed. I'm using MSDE2000 on the same machine. I think executingGenerator.ProjectDefinition.ConnectionString returns a CS w/o the password. Maybe it works only with Windows authentication?

I am downloading the lastest LLBLGen - then i will have alook at it.

I use the taskperformer with Connection strings that supply username and password - havn't tried it with Windows Auth. - But there should be no difference - because i am getting the whole ConString from the LLBLGen project.

I know the MSDE2000 SQLSERVER Version has somthing funny about the number of connections - i think only 5 or 6 conns are allowed. - Can't rember - Otis does mention it somewher in this forum - April i think.

[FOUND THE FUNNY THING WITH MSDE] MSDE executes 5 transaction statements per clock, or handles 5 connections at a time. Every 6th has to wait. ... (just very slow).

I don't think this is your problem...Standby i will take a look.

wayne wrote:

I am downloading the lastest LLBLGen - then i will have alook at it.

I use the taskperformer with Connection strings that supply username and password - havn't tried it with Windows Auth. - But there should be no difference - because i am getting the whole ConString from the LLBLGen project.

I know the MSDE2000 SQLSERVER Version has somthing funny about the number of connections - i think only 5 or 6 conns are allowed. - Can't rember - Otis does mention it somewher in this forum - April i think.

[FOUND THE FUNNY THING WITH MSDE] MSDE executes 5 transaction statements per clock, or handles 5 connections at a time. Every 6th has to wait. ... (just very slow).

I don't think this is your problem...Standby i will take a look.

That wouldn't cause him to get an access denied message. I tried it on the new version of LLBL and it works fine (with MSDE). What does your enum.config file look like?

Skeeterbug wrote:

That wouldn't cause him to get an access denied message. I tried it on the new version of LLBL and it works fine (with MSDE). What does your enum.config file look like?

It contains the following task:

<taskGroup description="Generate Enums"> <task name="Generate Enums" assemblyFilename="Gen_Enums.dll" taskPerformerClass="Gen_Enums.Performer"> <parameter name="No_Of_Tables" value="1"/> <parameter name="OutputfileName" value="DatabaseGeneric/LookupEnums.cs"/> <parameter name="EnumName_1" value="ApplicationKey"/> <parameter name="EnumType_1" value="int"/> <parameter name="SelectSQL_1" value="Select * from ApplicationKey Order by ApplicationKeyID"/> <parameter name="IDField_1" value="ApplicationKeyID"/> <parameter name="DescField_1" value="Description"/> </task> </taskGroup>

That wouldn't cause him to get an access denied message. I tried it on the new version of LLBL and it works fine (with MSDE). What does your enum.config file look like?

I tried it aswell with the new LLBLGen - No Problem.

Post your config file here - maybe there is something wrong with it - I see you already did. But that should not give you an access denied message.

I've uploaded it to the 3rd party section so everyone can have a look at it . Thanks Wayne for sharing this task performer

Hi obzekt

No - i can't find this problem. - I wonder is some of those field or tablenames in your SQL not reservedwords? I havn't check that.

Well, ok, I have added a some exception handling to try and find the problem. Get this version from http://196.36.190.121/LLBLGEN/TaskPerformers/EnumTaskPerformer.rar

If this version helps you i will pass in on to Otis.

Let me know.

[quotenick="wayne"]

But that should not give you an access denied message.

I downloaded and reinstalled LLBLGen Pro, rebuilt your TP, and still can't get it to connect to SQL. Regular code generation though works flawlessly.

So I would like to ask Otis how the ConnectionString is constructed when the catalog is refreshed and if it gets stored (incl. the password) inside the LGP.

Is it possible that ProjectDefinition.ConnectionString chokes if the db server name is like "mypc\vsdotnet"?

I 'm giving up after this because it is wasting everyone's time, thank you guys anyway, this forum rocks!

wayne wrote:

Well, ok, I have added a some exception handling to try and find the problem. Get this version from http://196.36.190.121/LLBLGEN/TaskPerformers/EnumTaskPerformer.rar

Excellent! Here's what happens:

The LGP I'm using has been created by another developer and initially held his SQL credentials which are different than mine. When I open the LGP though, I refresh the catalog providing my own credentials and save the LGP expecting the connection string to be totally overwritten, but is not.

As your exception handling exposed, ProjectDefinition.ConnectionString is still providing the old string to your TP which fails. It seems like a bug in the LLBLGen SDK.

mypc\vsdotnet

I use the IP address, not the server instance. What do you use Wayne?

It seems like a bug in the LLBLGen SDK.

Nothing that i can do about this then...Just have to wait till this get fixed.

I am NOT going to add a connection field into the config file... then i might aswell create the Task Performer as a seperate application.

I use the IP address, not the server instance. What do you use Wayne?

I use the Server Name mypc\vsdotnet - This looks like a second instance instalation of SQLServer.

wayne wrote:

I am NOT going to add a connection field into the config file... then i might aswell create the Task Performer as a seperate application.

Makes sense. But I did add that param and modified slightly your code so as to get me going in the meantime... Thanks again.

obzekt wrote:

wayne wrote:

Well, ok, I have added a some exception handling to try and find the problem. Get this version from http://196.36.190.121/LLBLGEN/TaskPerformers/EnumTaskPerformer.rar

Excellent! Here's what happens:

The LGP I'm using has been created by another developer and initially held his SQL credentials which are different than mine. When I open the LGP though, I refresh the catalog providing my own credentials and save the LGP expecting the connection string to be totally overwritten, but is not.

It doesn't do that as it seems. Which is a bug.

Wayne (or you) can work around it by checking the ConnectionElements hashtable in the project object which has key value pairs with the various connection string elements. You can also create a new connection string with these elements by calling project.DatabaseDriver.ConstructConnectionString(project.ConnectionElements);

I'll set the connection string after elements have been changed (and kept!)

Wayne (or you) can work around it by checking the ConnectionElements hashtable

Nah, i am just going to leave it as it as for now - people can modify the code and post in back if they want to.

Hmmm. I've read all the posts here and would like to add some comments.

Firstly not all lookup tables have numeric ids. Sometimes you have value-description pairs where the value is a string. It happened to me many times especially when I need to work with an existing database or rewrite an application where I have no control over this stuff. In such cases you can't use an enum. I usually use a class like so:

Friend MustInherit Class CreditCardType
     friend Const VISA = "VISA"
End Class

which you can use it just like an enum.

Dim strCCType as string = CreditCardType.VISA

Also, many times this kind of information is not written in any table. For example the design of the application can say that there are variours roles etc but they will bot necessarily be in a db table. In this case you could use an enum, but you would need to code it manually.

All this to say that probably, like Otis said in an early post in this thread, it would be great if he added all this to LLBLGen. We could manually specify lists of value-description pairs (where the value can be anything really) manually and/or specifying a db table as the source.

Talking about this, wouldn't it be cool if the LLBLGen designer supported custom plug-ins ? Someone else could develop this sort of feature and integrate it into LLBLGen without Otis needing to do it.. (Otis did you read? ;-))

Gui plugins are planned (the framework for that)

At the moment, it doesn't have a high priority though, but it will be added

Firstly not all lookup tables have numeric ids. Sometimes you have value-description pairs where the value is a string.

Friend MustInherit Class CreditCardType
friend Const VISA = "VISA"
End Class

Good Point. - It should be easy to add this - make the TP generated Constants aswell - i will look into this but i am not promissing anything soon.

Also, many times this kind of information is not written in any table.

The only other way to possible do this would be via the LLBLGen Designer as you suggested.-But is not currently possible .

wayne wrote:

Also, many times this kind of information is not written in any table.

The only other way to possible do this would be via the LLBLGen Designer as you suggested.-But is not currently possible .

It's a discussion if this information belongs inside a dal if it's not in a table. You can also argue it belongs to the constants list of the BL. It doesn't really matter where these constants are defined, it just matters that they are defined. The constants will be used in the BL mostly anyway, and the values are just transported to the DAL.

It's a discussion if this information belongs inside a dal if it's not in a table. You can also argue it belongs to the constants list of the BL. It doesn't really matter where these constants are defined, it just matters that they are defined. The constants will be used in the BL mostly anyway, and the values are just transported to the DAL.

Ok - Now i understand the way you are thinking...if is not in a table then it should not really be in the DAL..there for it is not LLBLGen's problem

heh

well, look at it this way: if you don't want to include dal related stuff in the GUI, you can work with the enums defined in the BL, not in the dal

No problem